iT邦幫忙

2024 iThome 鐵人賽

DAY 18
0

前面我們把 React native app 使用 redux 透過 api串接後端。但我們目前只有實作註冊系統而已,最精簡功能的的會員系統,除了註冊以外,應該還會有登入的部分,修改密碼,忘記密碼的功能還有修改使用者資訊。

再進階一點可能還會有分角色權限之類的,但我們這個專案先不用做到這麼複雜。

但其實在網路的世界,登入不是只是帳號密碼打對就好了。為了資料安全還還會需要有驗證的部分。不過我們先為了求快,不會做太過複雜的設計。

常見的後端會驗證實作

在會員系統的驗證方法中,主要有三種常見的驗證方式:Session-based 認證JWT(JSON Web Token) 認證和 OTHA(OAuth 授權協議)

Session-Based Authentication

這種方法使用伺服器來存儲用戶的會話(Session)。用戶登入後,伺服器會生成一個 Session 並將 Session ID 儲存在用戶的 Cookie 中。每次用戶發送請求時,伺服器會驗證 Cookie 中的 Session ID。

流程:

  • 使用者提交登入表單,伺服器驗證用戶帳密是否正確。
  • 如果驗證通過,伺服器會創建一個 session,並將 session ID 存入伺服器端的資料庫或內存。
  • 伺服器將 session ID 返回給用戶,並通常將其存在 cookie 中。
  • 後續請求中,用戶會攜帶 session ID,伺服器驗證該 ID 是否有效。
  • 驗證成功後,伺服器返回請求的數據。

優點

  • 資料只保存在伺服器,安全性較高。
  • 適合需要持久連線的應用,如即時聊天。

缺點

  • 需要伺服器維護 session 狀態,擴展性不如無狀態的 token 認證。
  • 在多伺服器環境下,session 共享變得困難。

Token-Based Authentication(JWT)

JWT(JSON Web Token) 是一種無狀態的認證方法,將使用者的認證資訊編碼成一個 Token,並且在每次請求中由用戶攜帶 Token,伺服器根據 Token 進行驗證。JWT 的內容可以包含用戶的身份資訊,因此無需存儲在伺服器。Token 會附加在每次請求的標頭(header)中,伺服器通過驗證 Token 來授權用戶的操作。

工作流程

  1. 用戶提交登入表單,伺服器驗證用戶帳密。
  2. 驗證通過後,伺服器生成一個 JWT(包含用戶資訊的 payload),並將其返回給用戶。
  3. 用戶在後續請求中將 JWT 放入 HTTP Header 中。
  4. 伺服器通過驗證 JWT 的合法性,確定請求的身份。

優點

  • 無狀態,不需要伺服器維護 session,擴展性高。
  • 可以在多個不同系統之間共享身份認證(如微服務架構)。
  • 支援跨平台,如 Web 和 Mobile。

缺點

  • Token 一旦生成,即便伺服器已經註銷用戶,Token 在有效期內仍然有效,安全性可能不足。
  • Token 的大小通常比 session ID 大,可能增加流量。

OAuth(第三方身份驗證)

OAuth(Open Authorization) 是一種用於跨應用程序間授權的開放標準協議。OAuth 並不僅僅是用來進行身份認證,它的主要目的是授權。例如,使用第三方服務(如 Google、Facebook 等)登入另一個網站,而無需輸入帳密。

流程:

  • 應用請求權限:使用者通過應用發送授權請求,應用會將使用者重定向到授權服務(如 Google)。
  • 用戶授權應用:用戶會在授權服務中登入,並選擇授權應用訪問特定範圍的資料。
  • 授權服務回應授權碼:當用戶同意後,授權服務會將授權碼(Authorization Code)返回給應用。
  • 應用換取 Token:應用使用授權碼向授權服務請求 Access Token(訪問令牌),這個令牌將允許應用訪問用戶的資料。
  • 應用訪問 API 資源:應用使用這個 Access Token 來調用 API 進行操作,如獲取用戶資料或發送數據。

優點

  • 無需存儲用戶密碼,提升安全性。
  • 用戶可以輕鬆地使用現有帳號進行登入,提升用戶體驗。

缺點

  • 實現比較複雜,尤其是在多方系統之間進行身份驗證。
  • 依賴第三方服務,第三方服務的穩定性會影響系統運行。

未來會希望可以加上OAuth的登入,例如 apple 或 line 登入。但應該不會做到這麼後面🤪

比較

認證方式 優點 缺點 適用場景
Session-based 簡單,適合小型應用 需伺服器維護 session 狀態,不易擴展 小型應用或即時應用,如聊天室
JWT 無狀態,易於擴展,跨平台支持 Token 無法在過期前失效,流量相對較大 適合微服務架構、多平台應用,如 API 服務
OAuth 無需存儲用戶密碼,提升安全性 實現複雜,依賴第三方服務 用戶可以使用第三方服務登入的應用

我們這個專案選擇使用JWT來實現,比較簡單,因為可以使用第三方套件直接使用。實作上比較簡單。明天會來設計一下簡單的資料庫還有 api文件開立的寫法再來是看能不能直接用 API文件讓 cursor直接實作出來。


上一篇
[DAY17] Redux Debugger
下一篇
[DAY19] 會員認證與登入系統實作
系列文
30天 使用chatGPT輔助學習APP完成接案任務委託30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言